Network Address Translation (NAT) has become a popular mechanism of enabling the separation of addressing realms. A NAT router must examine and change the network layer, and possibly the transport layer, header of each packet crossing the addressing realms that the NAT router is connecting. This causes the mechanism of NAT to violate the end-to-end nature of Internet connectivity, and disrupts protocols requiring or enforcing end-to-end integrity of packets.
An alternative to NAT is Realm Specific IP (RSIP) (see Request For Comment (RFC) 3102). RSIP is based on the concept of granting a client from one addressing realm a presence in another addressing realm by allowing the client to use resources (e.g., addresses, ports and/or other routing parameters) from the second addressing realm. An RSIP server replaces the NAT router, and RSIP-aware client on the private network are referred to as RSIP clients. RSIP requires ability of the RSIP server to grant such resources to RSIP clients.
RSIP allows a degree of address realm transparency to be achieved between two differently-scoped, or completely different addressing realms. This makes it a useful architecture for enabling end-to-end packet transparency between addressing realms. RSIP is expected to be deployed on privately addressed IPv4 networks and used to grant access to publicly addressed IPv4 networks. However, in place of the private IPv4 network, there may be an IPv6 network, or a non-IP network. Thus, RSIP allows IP connectivity to client on a host with an IP stack and IP applications but no native IP access. As such, RSIP can be used, in conjunction with DNS and tunneling, to bridge IPv4 and IPv6 networks, such that dual-stack hosts can communicate with local or remote IPv4 or IPv6 hosts.
Referring now to FIG. 1, in a typical scenario in which RSIP may be deployed, there is at least one client host 102 connected to a network 110a having one addressing realm (realm A), another client host 120 connected to a network 110b having a different addressing realm (realm B), and a gateway 104 that is connected to both networks 110a and 110b. As illustrated, hosts 102 and 120 belong to different addressing realms A and B, respectively. Gateway 104 has two interfaces: (1) Na on address realm A, and (2) Nb on address realm B. Executing on gateway 104 is an RSIP server 105 that has a pool of addresses in address realm B that it can assign to or lend to a client 103 on client host 102 and other clients on other hosts in address realm A. These addresses can be denoted as Nb1, Nb2, Nb3 and so on.
As is often the case, hosts within address realm A are likely to use private addresses while gateway 104 is multi-homed with one or more private addresses from address realm A in addition to its public addresses from address realm B. Thus, we typically refer to the realm in which client host 102 resides as “private” and the realm from which client host 102 borrows addressing parameters as the “public” realm. However, these realms may both be public or private. Moreover, address realm A may be an IPv6 realm or a non-IP address realm.
Client 103, wishing to establish an end-to-end connection to a client on client host 120 situated within address realm B, first negotiates and obtains assignment of public resources (e.g., addresses and other routing parameters of address realm B) from server 105. Upon assignment of these public resources, server 105 creates a mapping, referred to as a “bind”, of client 103′s private addressing information and the assigned resources. Such a bind enables gateway 104 to correctly forward inbound traffic generated by client host 120 for client 103.
Using the public resources assigned by server 105, client 103 tunnels data packets across network 110a to server 105. Server 105 acts as the end point of such tunnels, stripping off the outer headers and routing the inner packets onto the public realm (i.e., network 110b in the example shown in FIG. 1). As mentioned above, server 105 maps the public parameters assigned to client 103 to the private address used by client 103. When a packet from the public realm arrives at gateway 104 and it matches a bind, then server 105 will tunnel it to the appropriate host.
The RSIP RFC defines two basic flavors of RSIP: (1) RSA-IP and (2) RSAP-IP. When using RSA-IP, an RSIP server maintains a pool of available network addresses (e.g., IP addresses) to be leased by RSIP clients. Upon request, the RSIP server allocates an address to the client. Once an address is allocated to a particular client, only that client may use the address until the address is returned to the pool. Clients should not use addresses that have not been specifically assigned to them. The client may use any layer four address (e.g., TCP/UDP port) in combination with their assigned layer three (i.e., network) address.
When using RSAP-IP, an RSIP gateway maintains a pool of layer three and layer four addresses (e.g., IP addresses as well as pools of port numbers per address). RSIP hosts lease an IP address and one or more ports to use with it. Once an address/port tuple has been allocated to a particular client, only that client should use the tuple until it is returned to a pool. Clients should not use address/port combinations that have not been specifically assigned to them.
It is possible that server 105 may fail. What is desired, therefore, are systems and methods for detecting a server failure and gracefully recovering from the failure.